PASKAL V10.0: Implementation Overview 


by BILL FINDLAY 
0 READERSHIP 


1 BACKGROUND 
1.A HISTORY 
1.B THE PASKAL PROJECT 


2 How PASKAL WORKS 
2.A INPUT HANDLING, DIRECTIVES AND LEXICAL ANALYSIS 


2.B SYNTAX ANALYSIS 

2.C SEMANTIC ANALYSIS AND CODE GENERATION 

2.C.1 STACKS 

2.C.2 STATEMENTS 

2.C.3 EXPRESSIONS 

2.C.4 STORAGE ALLOCATION, ADDRESSING AND ASSIGNMENT 
2.C.5 SUBPROGRAMS 


3 PEEPHOLE OPTIMIZATION AND GLANCE 


4 ODDS AND ENDS 


REFERENCES 


0 Readership 


This document is intended for anyone wishing to understand, maintain, or enhance the KDF9 Pascal cross-compiler, 
PASKAL. PASKAL consists of a one-pass compiler, paskal, written in Pascal, working with a ‘peephole optimizer’ 
called glance, written in Ada 2012. It is supported by ee9 [Findlay3], my KDF9 emulator, by David Holdsworth’s ka13 
Usercode assembler, and by bash-compatible shell scripts. 


If you just want to use PASKAL, see PASKAL: Users’ Guide [Findlay6]. 


1 Background 
1.A History 


The long-running project to resurrect the KDF9 and its software in emulation reached something of a milestone when it 
became possible to compile and run the Whetstone Benchmark program using the optimising Kidsgrove ALGOL 60 
compiler. The Kidsgrove compiler generates Usercode, KDF9’s original assembly language, letting the user see how a high 
level language is mapped on to the KDF9 architecture. Unfortunately, ALGOL 60 is a rather intractable language, designed 
without much thought for implementation. In consequence the relationship of the source code to the object code can be 
non-obvious. Since my interest in the KDF9 resurrection project has always been primarily educational, I wanted to do 
better, and a Pascal [Wirth1] cross-compiler has the potential to make that possible. 


PASKAL is the great-grandchild of compilers written by Niklaus Wirth’s team at ETH Ziirich. Their initial compiler, 
written in Pascal for the CDC 6400 computer [Wirth2, Wirth3], was used in a half-bootstrap operation to provide an 
implementation for the ICL 1900 Series by a team at Queen’s University, Belfast (QUB), led by Jim Welsh [Welsh1]. This 
was used in turn to bootstrap a compiler for the ICS Multum minicomputer [Findlay1] by a team in the Computing Science 
Department of the University of Glasgow (GUCS). At both QUB and GUCS there was great interest in using Pascal as a 
teaching language, but both groups felt that the extant compilers were not entirely suitable for that purpose. The publication 
of the Revised Pascal language [Jensen1] had made them somewhat obsolete. It was also felt that improvements could be 
made to the clarity and portability of Zurich’s software. Consequently a new compiler was written, principally at QUB, but 
with the participation of David Watt and myself at GUCS in providing symbolic diagnostics [Watt1]. That compiler is 
PASQ [Welsh2]. Released in 1976, it saw widespread use in both industry and academia. 


ICL’s ‘New Range’, the 2900 Series, was incompatible with the 1900 Series, so the Computer Science Department at 
Southampton University (SOTON) decided, with the assistance of Imperial College, to port PASQ to their new ICL 2970 
[Rees1]. About that time it became obvious that a 2900 machine was destined for Glasgow as well, so I helped SOTON by 
retargetting enhanced symbolic diagnostics to the 2900 architecture, in return for a commitment that I would have free rein 
to use the resulting compiler for projects of my own. That work culminated in 1980 with the release of ICLOLPCOMPILE, 
and after much bureaucratic delay it was eventually officially distributed by ICL. 


1.B The PASKAL project 


The source texts of both PASQ and ICL9LPCOMPILE have been preserved and I have now used them as the basis for 
paskal, a cross-compiler targeting the English Electric KDF9 [Findlay2]. Once I learned of a usable Pascal compiler for 
both macOS and Linux that implements ISO Standard Pascal—the Free Pascal Compiler, fpc—I was able to strip the 
2900 Series dependencies from ICL9LPCOMPILE and to begin to replace them with KDF9 specifics. Testifying to the 
quality of its predecessors is that I was able to get something useful going in about 18 months of part-time work, despite 
long pauses due to recurrent post-Covid brain fog. 


With a realistic view of the effort involved in a full implementation, I have limited the scope of the project by leaving out 
some features of PASQ and ICL9LPCOMPILE. In particular, paskal does not provide source code execution profiles, 
retrospective tracing or full tracing. I was also prepared to limit or omit language features that do little for my educational 
objective. At time of writing, most packed types, set types with a base type of more than 96 values, file types, and the I/O 
features of Pascal, remain to be supported. Some or all of these may be added in future releases. I have also given little 
thought to the PASQ objective of providing the basis for a family of portable compilers. Gratefully capitalizing on the work 
done to that end by others in the past, I instead focus on generating clear, concise, idiomatic KDF9 Usercode. 
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In mitigation of these omissions, I have added two new non-standard features: the usercode ... end block, which allows 
Usercode statements to be included, in-line, and the include directive, which allows for inserting boilerplate code (a 
group of very basic output routines is provided, to be used in this way). 


paskal has been designed from the start to work in tandem with glance, a peephole optimizer originally developed to 
complement the Kidsgrove ALGOL compiler. It now has a Pascal mode, that manipulates paskal’s object code to make 
improvements that are difficult or impossible to achieve in one pass. paskal generates a valid object program, but it is 
one that can be significantly improved by glance, both in terms of efficiency and in terms of its educational value. 


Saving space is a concern throughout PASKAL, as a KDF9 program has only 8K words (48K bytes) for machine code, out 
of a possible 192K byte address space. Consequently, I take every opportunity to reduce the size of the object code while 
bearing in mind that it should be readily understandable. Fortunately these objectives are very compatible. 


2 How PASKAL works 


The following description gives a synoptic view of the logic of paskal, much of it inherited, via ICL9LPCOMPILE and 
PASQ, from the work of the Ziirich compiler writers. 


Structured languages like Pascal are recursively defined: statements contain subordinate statements, expressions contain 
subexpressions, and types are defined in terms of other types. This is reflected in the logic of the compiler, which is 
implemented as groups of mutually recursive routines. For example, the routine that compiles a statement (statement) 
can call the routine that compiles an if statement (if __ statement), which in turn contains two calls of statement, one 
for the then part and one for the else part, either of which might very well make further calls of if_ statement. 


This recursion works, as it does in most high level languages, by means of a stack of ‘activation records’ or ‘frames’, each 
containing the local data of an active call of a compiler routine. A stack frame is created when a routine is called and is 
deallocated when it exits. Local variables of these routines, held in their stack frames, constitute an ad hoc stack of 
compilation data. These variables are independent of those in any dynamically enclosing call of if statement, which 
might be made to handle a lexically enclosing if statement, and would have its own instances of these variables. 


2.A Input handling, directives and lexical analysis 


paskal’s lexical routines are responsible for reading the source code, which entails handling include files; for formatting 
and printing the source listing, which entails recording and displaying error indications; for handling directives; and for 
preparing the source code for lexical and syntactic analysis. Pascal identifiers and reserved words are case-insensitive, but 
the contents of strings are not. Accordingly, the source listing reproduces the input verbatim, but the compiler actually 
processes a version of the input in which letters outside strings have been converted to lower case. 


Lexical analysis is performed by get_ symbol, which consumes characters of input until it has recognised a fully formed 
lexical token. A token’s kind is indicated by a value of the enumeration symbol_type. In the case of a symbol of class 
ident, the global variable spelling is set to its text. In the case of a literal constant, the global variable constant is 
set to its value. String constants are stored in the form of a linked list of segments, each, except possibly the last, containing 
16 characters. If the string contains exactly 16 characters it is also stored in constant as a value of type alfal6; a 
string of 8 characters is also stored as a value of type alfa8. get_symbol recognises integer constants in octal as well 
as decimal, with the # syntax used by ee9. It also recognises two non-Standard reserved words: usercode and otherwise. 


2.B Syntax analysis 


Syntax analysis is conducted on the basis that Pascal is (approximately) an LL(1) language, which can be analysed by 
recursive descent with a 1-symbol context. This fails when, for example, a statement begins with an identifier. That might 
introduce either an assignment or a procedure call. In cases like this the compiler uses semantics to decide how to proceed; 
for example, by looking up the identifier’s type in the symbol table to determine the correct course of action. 


Here is the syntax analysis logic abstracted from the compiler’s repeat _statement procedure. It loops over the 
analysis of the statements in the repeat statement’s body until it encounters its terminating until, at which point it calls 
expression to compile the Boolean termination condition: 


procedure repeat statement; 

begin 

repeat 
get_next_symbol; 
statement(statcontext + [semicolon, until_symbol]); 
until symbol <> semicolon; 

if symbol = until symbol then 
begin 


get_next_symbol; 
expression(substatcontext) ; 


end 
else 
fail(53); 


end; 


2.C Semantic analysis and code generation 
2.C.1 Stacks 


In addition to its activation record stack, paskal manipulates two explicit stack data structures, the scope stack (SS) and 
the operand stack (OS). SS and OS are implemented rather differently. OS is a linked list, cells being added and removed 
only at one end. SS is an array of records, indexed by a variable that tracks the depth of block nesting. Items are added to 
and taken from OS on a rather haphazard basis, which is a prolific source of compiler bugs; SS is handled in a more 
disciplined manner. These stacks are further described in the following. To assist in debugging paskal, I have added the 
procedures print _scopes, which outputs a résumé of SS, and put_operands, which does the same for OS. There is 
also put_operand which provides diagnostic information for a single operand that need not be in OS. 
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SS has an entry, of type scope_model, for each procedure or function block within which the compiler is currently 
processing statements. It is set up by proc_declaration, which analyses any formal parameters and then calls the 
block procedure to handle any nested label, const, type, var, procedure or function declarations, before calling body to 
handle its executable statements. An SS entry contains both a pointer to the block’s symbol table (which is implemented as 
a binary search tree), and a summary of the block’s attributes that are relevant to code generation. 


PASKAL holds various attributes in SS entries, namely: does_calls, has_interlude, is nonlocal target, 
needs_a_static_link, interlude, next_param_address, next_local_ address, first_1 value, 
and local_frame_size. They are used at the end of the block to generate tailored preludes and postludes. See §2.C.5. 


A complication, perhaps unique to Pascal, is that SS from time to time has a top entry which designates a record variable 
rather than a block, so that with statements can be processed on the basis of the convenient fiction that a record is a block 
and that its fields constitute ‘local variables’. 


While SS is concerned with block declarations, OS is focussed on expressions. It simulates the state of a hypothetical 
machine with a postfix (‘Reverse Polish’) architecture. The machine-independent parts of the compiler isolate operands and 
place models of them on OS. When a runtime operation is to be generated, the compiler calls a machine dependent routine 
for that purpose, which takes models of its operands from OS, generates any code needed to compute the result, and then 
pushes a model of that result on to OS. Each such routine has the task of converting the operations of the hypothetical 
machine into those of the target architecture. PASKAL benefits greatly from the fact that KDF9 actually is a postfix 
machine, so that converting hypothetical machine operations into KDF9 Usercode is (somewhat) straightforward. 
2.C.2 Statements 
With that background, here is a complete example—the compiler code for processing repeat statements. Syntax analysis is 
displayed in black, Pascal semantic analysis in blue, and portable code synthesis in green: 
procedure repeat statement; 
var 
repeat_top sequence : code sequence; 
bool_entry_ptr : operand pointer; 
begin { repeat_statement } 
start_code_sequence(repeat_top sequence, unaligned); 
repeat 
get_next_symbol; 
statement(statement_context + [semicolon, until_symbol]); 
until symbol kind <> semicolon; 
if symbol_kind = until symbol then 
begin 
log source _as_ comment; 
get_next_symbol; 
expression(substatement_context) ; 
if not compatible(the expr _type ptr, bool_type) then 
fail(144); 
unstack(bool_entry_ ptr); 
with bool entry ptr* do 
if kind <> constant_operand then 
stack(bool_entry ptr); 
jump_on_ false(repeat_top_ sequence) 
else 
if the_constant.bool value = kdf9 true then 
begin 
notify(160); 
end 
else 
begin 
notify(171}- 
jump(repeat_top sequence); 
end; 
end 
else 
fail(53); 
decrement_nesting_ level; 
end; { repeat_statement } 
A label is planted by start _code_ sequence at the top of the object code loop. The body of the source code repeat 
statement is handled by the compiler’s repeat statement, which iteratively and recursively calls statement to generate 
code for the statements in the loop body. When until has been found and passed, the call of expression handles the 
termination condition, a model of which is left in OS. That is immediately checked to ensure it has Boolean type, failing 


which error 144 is flagged in the source listing. bool_entry_ptr is then set, to allow examination of the model of the 
expression. If it indicates a constant, two special cases are considered. A true value means that the loop will terminate after 
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one execution of its body, and the compiler alerts the programmer to this with warning number 160. A false value means 
that the loop will never terminate, and the compiler alerts the programmer to this with warning number 171. Although 
suspicious, this is not illegal, so jump generates an unconditional jump to the label set at repeat_top sequence. 
More usually, the expression must be tested at run time. This is done by jump_on_ false, which generates a conditional 
jump back to repeat_top sequence. Like a KDF9 conditional jump order, which deletes its determining operand 
from the NEST, jump_on_ false deletes the Boolean from the OS. 


The source listing produced by PASKAL includes an indication of the syntactic nesting of compound statements, to make it 
easier to see where this has gone wrong, e.g. if there is an extra begin or missing end. For these purposes, the body of a 
repeat statement is treated as a compound statement, and the call of decrement_nesting_level notes its end. 


Here are the code generation routines used above. Code emission is a simple matter of using Pascal write statements to 
output fragments of text to the object code file (obj). I have added some explanatory remarks in italics: 


procedure start_code_ sequence (var sequence : code sequence; alignment : Boolean); 
begin 
if Usercode_is wanted then 
with sequence do 
begin 
generate a new Usercode label number: 
next_label_ number := next _label_ number + 1; 
word aligned := alignment; 
record the new label number in sequence for future reference: 
target_label := next _label_ number; 
place the Usercode label: 
if word_aligned then 
write(obj, '*'); 
writeln(obj, target_label:0, ';'); 


end; 
end; 
procedure jump (destination : code_sequence) ; 
begin 


if Usercode_is wanted then 
writeln(obj, 'J', destination.target_label:0, ';'); 


end; 
procedure jump on false (var destination : code_sequence); 
var 
bool_entry ptr : operand pointer; 
begin 
if Usercode_is wanted then 
begin 


access the model of the Boolean expression: 
unstack(bool_ entry ptr); 
with bool entry ptr* do 
if is_in_ the nest then 
writeln(obj, 'J', destination.target_label:0, '=Z;') 
else 
case kind of 
reference: 
begin 
the expression is a Boolean variable; force it into the NEST: 
fetch_the_value_of(bool_entry ptr); 
now the Boolean value is in the NEST, so generate a Jlabel=Z order referring to the label recorded in destination: 
writeln(obj, 'J', destination.target_label:0, '=Z;'); 
end; 
constant _operand: 
when we know the value of the Boolean is true we need generate no object code at all: 
when we know the value of the Boolean is false we can generate an unconditional jump: 
if the_constant.bool value = kdf9 false then 
jump(destination); 
end; {case} 
free_stack_entry(booleanentry) 
end; 
end; 


The effect of this logic is that the following fragment of Pascal source code: 


repeat r 
j= jei; 
until j = 0; 
gets converted into the following lines of Usercode: 
(line 67 "repeat"); 
53; 
(line 68 "j := j - 1;"); 
Y6; NEG; NOT; =Y6; 
(line 69 "until j = 0;"); 
Y6; ZERO; SIGN; ABS; NEG; NOT; J53=Z; 
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Post-processing by glance turns this into the simpler, shorter and faster: 


(line 67 "repeat"); 

53; 

(line 68 "j := j - 1;"); 
Y6; NEG; NOT; DUP; =Y6; 
(line 69 "until j = 0;"); 
J53#2Z; 


2.C.3 Expressions 


The co-ordinating routine for the processing of expressions is expression, which is nested within statement. The 
hierarchy of operator precedence in Pascal is paralleled by the hierarchy of procedures within expression that process 
subexpressions: expression deals with formulations that in general consist of two comparands connected by a 
comparison operator; comparand handles terms connected by +, -, and or operators; term handles factors connected 
by *, /, div, mod and and operators; and factor handles ‘elementary’ expressions, namely constants, variables, set 
constructors, function calls and parenthesized subexpressions. 


Functions may be routines declared in the program, or be library routines (e.g., arctan, cos, exp, log, power, round, 
sin and trunc), some of which are treated as ‘intrinsics’ that can be implemented inline by a few orders (abs, chr, 
odd, ord, pred, sqr, succ). Declared functions require essentially the same treatment as declared procedures, but 
library functions are supplied in the Usercode epilogue that the compiler appends to the object program. paskal processes 
intrinsics essentially as if they were operators, rather than functions. 


One complication is that Pascal allows a subexpression of type integer (or its subranges) to appear as an operand in an 
expression yielding a real. In the cases of +, -, * and power, the result is real if either operand is real. In the case of 
/, the result is always real. (div and mod do not admit real operands.) If both operands of +, -, * and power are 
integer, the expression is processed by dyadic_int_ operation; if either is real, dyadic_real_ operation 
is used. 


A further complication is the handling of constant operands. No code is generated for these until they are combined with a 
non-constant operand. This deferral lets paskal evaluate constant subexpressions at compile time. In turn that lets it 
optimize control structures and address calculations with constant determining expressions. 


paskal adds a little more complexity in the form of non-Standard facilities. Firstly. it provides the @v construct, which 
yields the address of the variable v as an integer and is almost trivial to implement. Secondly, it provides an overloaded 
function, power, in mitigation of Pascal’s lack of an exponentiation operator. It is handled as if it were a dyadic operation, 
with different treatments for integer and real operands. 


For example, here is how identifiers are treated by factor: 


search scopes for([const_class, var_class, field class, func_class], factor_ptr); 
get_next_symbol; 
case factor _ptr*.class of 
const_class: 
with factor ptr“ do 
begin 
stack_constant(values); 
expr_type ptr := id_type ptr; 
end; 
var_class, field class: 
begin 
selector(factor_context, factor_ptr); 
expr type ptr := var type ptr; 
end; 
tune class: 
begin 
call(factor_context, factor _ptr, must_check_ overflow) ; 
end; 
end; 


The selector procedure coordinates the addressing, fetching and storing of declared variables and subprogram parameters. This is 
described more fully in §2.C.4. 


This document is licensed under a Creative Commons Attribution 3.0 License: http://creativecommons.org/licenses/by-nc-sa/3 .0/ 5/9 
© William Findlay, last document revision: 2024-01-16 


PASKAL V10.0 


And here is the substance of term: 


factor(term_context + [mulop]); 
while symbol = mulop do 
begin 
term type := expr_type ptr; 
this operator := operator; 
get_next_symbol; 
factor(term_context + [mulop]); 
case this operator of 


mul _op: 
plus_minus_ mul(term_type, mul_op); 
slash: 
if (compatible(term_type, int_type) and compatible(expr_type ptr, real _ type) ) 
or 
(compatible(term_type, real_type) and compatible(expr_ type ptr, int_type) ) 
or 
(compatible(term_type, real_type) and compatible(expr_type ptr, real _ type) ) 
then 
begin 


real_dyadic_operation(slash, must_check_overflow) ; 
expr_type ptr := real _ type; 
end 
else 
begin 
expr_type_ ptr := real _ type; 
fail(134); 
end; 
div_op, mod_op: 
begin 
if not compatible(term_ type, int_type) or 
not compatible(expr_ type ptr, int_type) then 
fail(134); 
int_dyadic_operation(this operator, must_check_ overflow) ; 
expr_type ptr := int_type; 
end; 
and_op: 
begin 
if compatible(term_type, bool _type) and 
compatible(expr_ type ptr, bool_type) then 
bool _dyadic_operation(and_op) 
else 
fail(134); 
expr_type_ptr := bool type; 
end; 
end; 
end; 


plus_minus_mul is also called from comparand. It passes the baton as needed to int_dyadic_operation, 
real _dyadic_operation, or set_dyadic_operation. These latter routines have a conceptually simple task in 
paskal. For example, the logic that handles subtraction for integer operands is, in the most general case: 


fetch _both_of(left_operand.entry, right _operand.entry, rev_may_ be needed); 
write(obj, '-; '); 


where the call of fetch _both_of ensures that the operands are nested in the correct order (left in N2, right in N1) for 
the KDF9 subtract instruction. For a commutative operation the last parameter is given as rev_is not _needed. 


There is actually a lot more to int_dyadic_operation than that, because it exploits constant operands to generate 
better Usercode, e.g. by suppressing identity transformations and by reducing multiplication to shifting-and-addition when 
possible. A similar, but smaller, set of optimizations is effected by real_dyadic_operation and by the translation of 
set expressions, including singleton sets and interval sets. real_dyadic_operation is also responsible for converting 
an integer operand to real if necessary. These optimizations improve code size and speed, and provide a better illustration 
of the capabilities of the KDF9 architecture. 


Code generating routines of paskal have a var parameter—typically called must_check_overflow—that returns a 
synthesized attrribute of the subexpression, which is true if its evaluation might cause an overflow at runtime. This is used 
to condition the generation of code to check for overflow —if such checking is enabled by the check option—before the 
value is assigned. When checking is enabled, assignment to a variable of a subrange type also ensures that the value of the 
expression is within the type’s bounds. An effort is made to reduce the cost of range checking when the range bounds 
include the values 0, +1 and +maxint, and when overflow checking is also called for. When not done inline, the checking 
is performed by appropriate entries to the library routine P117. 
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2.C.4 Storage allocation, addressing and assignment 

A full account of the layout of storage in the object program is given in the document PASKAL: Object Program Structure. 
For present purposes, we need only note that variables and parameters are stored in stack frames that are set up on entry to 
(sub)programs, that the active stack frame is pointed to by M1, that the top of the stack (i.e. its first free word) is pointed to 
by M2, and that the current stack frame of the closest-enclosing scope (if any) is pointed to by M3. Parameters have 
negative offsets from a frame pointer and local variables have positive offsets. 


Local data is addressed relative to M1, that in the enclosing scope relative to M3, and that in an outer scope relative to M4, 
which is set (by one more static link fetches, or by a calling a library routine) to point to that scope’s current stack frame. In 
principle, global variables—the ‘locals’ of the main program—are addressable in the same way as the locals of any 
subprogram, but since their addresses are fixed, for clarity and indexing efficiency paskal refers to them simply by their 
Y store name, e.g. as Y5. 


There are two complications: var parameters and array subscripting. 


A var parameter is passed to a subprogram as the address of its first word. That address is evaluated, and then stacked by 
using the KDF9 order =MOM2Q, which stores it at the address in M2, i.e. the top of the stack, and increments M2 to the 
stack’s next free word. A reference to a var parameter within the subprogram fetches that address from the stack frame, 
puts it into M4, and uses M4 in the code to fetch or store it. Pointer-based references are handled similarly. 


Array subscripts are evaluated in the NEST and then put into M15. A global array is accessed by an order of the form 
YyM15. Local variables are more complicated, because their stack frames are not at fixed addresses, so that code is needed 
to add M1 into M15. This also applies, mutatis mutandis, to non-locals based at M3 and M4. So a value parameter or a 
declared variable is accessed by an order of the form EeM15, where e is the position of its notional 0-th element in its stack 
frame. The address of a var parameter array is put into M4, e is added, and it is accessed by an order of the form M4M15. 


fetch_the address of, fetch _the value_of, fetch _both_of, store, and simple access manage 
access to declared variables and parameters. All except simple access take one or more operand pointer 
arguments identifying the variable(s) involved. 


Accessing variables and formal parameters is divided between the fetch_*/store_* routines and simple_access, 
which writes code using the block level and frame offset. Although it takes account of indirection (through a var parameter 
or pointer) and of a subscript (which has already been evaluated and is in the NEST), its main job is determining which 
frame pointer to use. The other routines direct simple_access after having analysed what needs to be done. 


fetch_the address of uses simple access to write code that nests the address of a variable, so that it can be 
stacked as an actual var parameter, for example. 


fetch _the_value_of has much in common with store, but is more complicated. If its operand is already nested it 
does nothing. If called to fetch a constant it may invoke one of another group of specific routines with names of the form 
fetch_* constant that write code to nest constants of various types. 


fetch _workspace and store workspace address local temporary locations (in the current subprogram’s stack 
frame) that are used to store values that must be preserved during the execution of for statements and with statements. 


fetch the static_link_ for writes code to generate the static link for a designated subprogram. This is nested 
when the subprogram is called, or pushed onto the stack when the subprogram is passed as the closure corresponding to a 
procedural or functional parameter. 


Assignment is mediated by the assignment procedure. A simple value is transferred by a fetch order and a store order. 
This is done twice over for a value taking two words, such as a set. assignment also notes when a one-word set value is 
assigned to a two-word variable, or vice versa, and writes code to append an all-zero word, or to erase the extra word from 
the NEST. If the source operand is of an ordinal type, and runtime checking is enabled, assignment writes code to check 
that its value is in the declared range of the destination. For a real operand it may write code to check for overflow. 


Records and arrays of more than two words are copied by a library routine; the call is written by assignment. 

There are two distinct address values associated with a variable: its frame offset and its adjustment. The offset, f, identifies 
the position of its first word in the frame. For local entire variables that becomes the value used in orders of the EfMk type. 
In the case of the i-th element of an array of type [J/..u] of T, the adjustment has the value —/*sizeof(T). This takes account of 
the fact that, element / of the array being located at the 0-th word of its storage area, with offset f, the position of element i 
is given by f+(i-l)*sizeof(T). This is actually evaluated as g+i*sizeof(T), where g = f-l*sizeof(T) is computed by paskal. 
Constant subscripts are folded into the adjustment so that, if it has only constant subscripts, an array element is addressed as 
if it were an entire variable. 

All this applies, mutatis mutandis, to arrays of more than one dimension. 

For a record field, the offset identifies the variable, var parameter, or pointer that locates the record, and the adjustment 
gives the position of the field relative to the first word of the record, somewhat like subscripting with a constant. 


An annoyance caused to one-pass compilers by the syntax of assignment statements, with the destination to the left of the 
source, is that any subscripts of the destination variable are evaluated before the source and thus find themselves in the 
wrong place in the NEST after the source has been evaluated, requiring a REV order to set things right. When possible, 
paskal directs glance to reverse that order of evaluation, removing the now-unwanted REV. 
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2.C.5 Subprograms 

The need to economise on order syllables strongly influences the coding of subprogram calls, which minimise the amount 
of code at the call site. Apart from stacking actual parameters and executing the subroutine jump, the call/return protocol is 
instantiated just once, within the subprogram itself. The entry sequence is called the prelude and the exit sequence is called 
the postlude. Analysis of the characteristics of each subprogram, P, is carried out to allow its prelude and postlude to be 
tailored to its specific requirements. 


The properties considered are: 

e whether P calls subprograms, other than library routines 

e whether P declares local variables or reserves local workspace 

e whether P declares parameters 

e whether P accesses non-local variables, other than global variables 

e whether P declares a label that is the target of a non-local goto statement in a nested scope 


It is not possible to completely suppress the nesting of a static link when P accesses no non-locals, because it might be 
passed to another subprogram as, and there called as, a procedural or functional formal parameter, and there can be no 
specific knowledge of P at the point of such a call. A routine accessing no non-locals is therefore given 0 as a dummy static 
link and its prelude merely erases it from the NEST. 


If a subprogram is the target of a non-local goto, paskal also generates an interlude for it. This restores as many of Q1, 
Q2 and Q3 as necessary, before re-entry to the scope at the designated label. This has the effect of trimming the stack back 
to the extent of the target scope’s stack frame. 


The prelude, postlude and interlude can be generated by paskal no sooner than immediately following the subprogram 
body, so the prelude ends with a jump to the start of the body. glance moves the prelude to its proper place and removes 
the now-redundant jump. 


See the procedures proc_prelude, proc_postlude and proc_interlude in paskal for the exact preconditions 
permitting optimization of these sequences. 
3 Peephole optimization and glance 


The glance program reads in a complete Usercode object program and uses hints left in the Usercode by paskal, inter 
alia, to make improvements that are not easy to implement in paskal itself. 


A leaf procedure is one that makes no calls to declared subprograms. This lets local variables be statically allocated within 
the Q store, access to which is faster and more concise than access to main store. paskal signals this possibility with a 
hint in the comment attached to a leaf routine’s postlude, and glance takes this hint, converting accesses to, at most, the 
first 10 local variables into accesses to, at most, Q5 through Q14. It is not possible to allocate a variable to the Q store if its 
address is needed, e.g. in order to subscript it, so paskal also informs glance of the lowest-addressed such variable and 
glance limits its transcription to those with lower stack frame offsets. 


Assignment to a variable v is often followed by its use as the first operand of the immediately succeeding statement. 
paskal flags assignments for glance, which checks for reuse, replacing code of the form: ‘ =v; v;’ by: ‘DUP; =v;’. 


Conditional jumps, such as the the ‘jump if false’ sequences that drive if statements and while loops work with Boolean 
values that paskal generates code to evaluate. glance replaces a Boolean evaluation and jump by a simple jump testing 
against 0, so long as it is not part of a more complex Boolean expression involving the and and or operators. See the 
example at the end §2.C.2. 


Other improvement made by glance include: 

e moving subprogram prelude code from the end of a body to its start, deleting a now-redundant jump 

e converting a jump on condition c over an unconditional jump with destination d, to a jump on condition not c to d 

e avoiding immediately re-fetching, in a following statement, a value that has just been assigned 

e replacing code with shorter and/or faster equivalents, for example replacing: “Q5; =06;” by “O5TOQ6;” 

e improving the indexing of global arrays in leaf routines, for example replacing: “Q6; =Q15; Y9M15;” by “Y9M6;” 
e deleting redundant code that has no continuing effect, for example: “REV; REV;” 

e deleting fetches of words subsequently erased, for example replacing: “Y21; Y20; REV; ERASE;” by “Y20;” 

e deleting the second of two consecutive unconditional jumps with no intervening label. 
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4 Odds and ends 


If you compare paskal with PASQ or ICL9LPCOMPILE you will see that I have liberated the code from the straitjacket 
of the 80-column card image and have exploited to the full the ability to have underscores in long identifiers. This is work 
in progress, so identifiers appearing here in examples may well have changed if you look at up-to-date source code. 


Can you think of anything else that needs explanation? If so, let me know: kd£9@findlayw.plus.com. 
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